### Rozdział. Bezpieczeństwo – hardening ponad „wtyczkę” – jak zabezpieczyć serwis od fundamentów i dobrze reagować na incydenty

Wtyczka bezpieczeństwa to jak alarm w domu. Warto go mieć, ale jeśli drzwi są cienkie, okna nieszczelne, a klucze leżą pod wycieraczką – alarm niewiele pomoże. Hardening to wzmocnienie konstrukcji: ustawienia serwera, aplikacji i kont, które utrudniają atak i ograniczają skutki błędu. W tym rozdziale przeprowadzę Cię przez praktyczne, „ponad wtyczkę” warstwy ochrony: od nagłówków bezpieczeństwa i blokad nadużyć, przez kopie zapasowe bazy i plików, po politykę haseł i 2FA. Na koniec dostaniesz prostą procedurę reagowania na incydent: co odłączyć, co przeskanować, co przywrócić i co zmienić, by sytuacja się nie powtórzyła.

#### Najlepsze praktyki serwera: zamykamy „otwarte furtki”

Zacznijmy od tego, co dzieje się „poniżej” CMS-a. To tu zatrzymasz wiele ataków zanim dotrą do aplikacji.

- Nagłówki bezpieczeństwa HTTP – niewidoczna, ale skuteczna tarcza
  - Content-Security-Policy (CSP): definiuje, skąd wolno ładować skrypty, style, obrazy. Minimalna wersja może blokować wstrzyknięte skrypty XSS. Na start użyj trybu „report-only”, by zobaczyć, co realnie ładuje strona, a potem włącz egzekwowanie.
  - X-Content-Type-Options: `nosniff` – przeglądarka nie będzie zgadywać typu pliku.
  - X-Frame-Options lub `frame-ancestors` w CSP: `DENY` lub `SAMEORIGIN` – utrudnia clickjacking.
  - Referrer-Policy: np. `strict-origin-when-cross-origin` – ogranicza wycieki URL-i z parametrami.
  - Permissions-Policy: wyłącz to, czego nie używasz (kamera, mikrofon, geolokalizacja).
  - Strict-Transport-Security (HSTS): wymusza HTTPS (z ostrożnością – włącz, gdy masz pewność stabilnego HTTPS).
  - Praktyka: dodaj nagłówki na poziomie serwera (Nginx/Apache) lub przez CDN/WAF (Cloudflare/Akamai). Testuj w „Security Headers” i w konsoli przeglądarki.

- Ograniczanie wektorów ataku w WordPress (lub innym CMS)
  - XML-RPC: jeśli nie używasz (np. zdalnych publikacji), wyłącz. To popularna brama do brute force i DDoS.
  - REST API: nie wyłączaj „na ślepo”, ale ogranicz ujawnianie wrażliwych danych (np. lista użytkowników) i chroń operacje wymagające autoryzacji.
  - Wersjonowanie: nie ujawniaj wersji CMS i wtyczek w kodzie HTML (nagłówki, meta). To ułatwia skanowanie podatności.

- Logowanie i rate limiting: dławi się atak, zanim urośnie
  - Ogranicz liczbę prób logowania (np. 5 prób, potem blokada IP na 15–30 min). Rób to na poziomie serwera/aplikacji lub WAF.
  - Captcha/honeypot na formularzach logowania i rejestracji. Prosta przeszkoda redukuje boty o rząd wielkości.
  - Rozważ niestandardowy URL logowania (security through obscurity nie jest rozwiązaniem, ale utrudnia masowe skrypty).
  - WAF/CDN: reguły blokujące znane wektory (SQLi, XSS), filtrowanie ruchu z podejrzanych ASN, limit zapytań per IP (rate limit).

- Uprawnienia plików i segregacja środowisk
  - Pliki/ katalogi: minimalne prawa (np. 640/750), właścicielem plików niech będzie użytkownik inny niż proces serwera (separacja obowiązków).
  - Oddziel środowiska (prod/stage/dev) – osobne bazy, inne klucze, brak publicznego dostępu do dev/stage.
  - Wyłącz listowanie katalogów i dostęp do plików konfiguracyjnych/ backupów przez WWW.

- Szyfrowanie i tajemnice
  - HTTPS wszędzie (Let’s Encrypt to szybki start). Wymuś TLS 1.2+.
  - Klucze/sekrety w zmiennych środowiskowych lub managerach sekretów (nie w repo). Rotuj okresowo.

Te ustawienia robi się raz, a potem głównie utrzymuje. Zmniejszasz powierzchnię ataku i „hałas” w logach.

#### Kopie zapasowe: baza i pliki osobno, test przywracania naprawdę wykonany

Backupy to ostatnia linia obrony. Liczą się szczegóły: gdzie, jak często, jak długo i czy umiesz je przywrócić.

- Dlaczego osobno?
  - Baza danych (treści, ustawienia, użytkownicy) i pliki (media, motywy, wtyczki) zmieniają się inaczej. Baza zwykle częściej, pliki rzadziej. Osobny harmonogram i strategie oszczędzają miejsce i czas.

- Harmonogram i retencja
  - Baza: przy stronach dynamicznych – co 4–12 godzin; przy mniejszej dynamice – codziennie. Retencja: 7–30 dni w zależności od wagi projektu.
  - Pliki: tygodniowo lub przy zmianach (deploy). Retencja: 2–4 tygodnie + miesięczny snapshot.
  - Off‑site: trzymaj kopie poza serwerem (S3/Backblaze/Wasabi/Google Cloud Storage). Kopia na tym samym serwerze to nie backup – to kopia do stracenia.

- Szyfrowanie i dostęp
  - Szyfruj backupy w spoczynku i w transferze. Dostęp ogranicz do minimalnej liczby osób, z 2FA do panelu backupów.

- Test przywracania
  - Raz na kwartał wykonaj próbne przywrócenie na środowisko testowe: baza + pliki. Zanotuj czas i kroki. To jedyny sposób, by wiedzieć, że backupy działają.

Dopiero backup, który potrafisz odtworzyć, jest prawdziwym zabezpieczeniem.

#### Polityka haseł i 2FA: najmniejszym kosztem zamykasz najczęstsze włamania

Najwięcej incydentów to nie „filmowe” zero‑daye, tylko przejęte loginy.

- Hasła
  - Długie > skomplikowane: 14–16 znaków (frazy) są lepsze niż krótkie z symbolami. Wymuszaj minimalną długość i zakaz recyklingu starych haseł.
  - Menedżer haseł (1Password/Bitwarden) dla zespołu. Koniec z „admin123!” w Excelu.

- 2FA (uwierzytelnianie dwuskładnikowe)
  - Włącz dla wszystkich kont administracyjnych (CMS, hosting, CDN, ESP, analityka). Aplikacja TOTP (Authy/Google Authenticator) lub fizyczny klucz (YubiKey) dla krytycznych paneli.
  - Recovery codes: przechowuj bezpiecznie i testuj, czy działają.

- Dostępy i uprawnienia
  - Zasada najmniejszych uprawnień: rolę „Administrator” ma mieć minimalna liczba osób. Reszta – „Editor”, „Author” itp.
  - Współdzielenie: zamiast jednego konta „admin”, każdy ma swoje. Po odejściu z zespołu – natychmiastowa dezaktywacja.

Te trzy kroki minimalizują ryzyko „przejęcia na hasło” – najczęstszej przyczyny włamań.

#### Procedura incydentu: jak reagować szybko i z głową

Nawet najlepsza ochrona nie daje 100% gwarancji. Liczy się to, co zrobisz w pierwszej godzinie.

- 1) Izolacja – zatrzymaj krwawienie
  - Jeśli podejrzewasz włamanie lub masowe błędy: zablokuj zapisy (maintenance/offline), ogranicz publiczny dostęp przez WAF (tylko Twój IP), w razie potrzeby odłącz instancję od ruchu za CDN.
  - Zrób migawkę bieżącego stanu (snapshot dysku/bazy) do analizy forensycznej, zanim cokolwiek nadpiszesz.

- 2) Skan i wstępna diagnoza
  - Przeskanuj pliki pod kątem malware (np. skaner serwerowy, narzędzia od dostawcy hostingu; w WP – porównanie plików core z repo).
  - Przejrzyj logi: nietypowe logowania, nowe konta użytkowników, nieznane pliki w `wp-content/uploads`, żądania POST do dziwnych endpointów.
  - Sprawdź integracje i klucze (API do ESP, płatności) – czy nie ma nadużyć.

- 3) Przywrócenie do bezpiecznego stanu
  - W przypadku infekcji: najszybsza metoda to przywrócenie czystej wersji plików core i motywów/wtyczek z repozytorium, usunięcie nieznanych plików, a następnie odtworzenie własnych customizacji z zaufanego repo.
  - Jeśli skala zniszczeń jest duża: przywróć całość z najbliższego czystego backupu (baza + pliki). Upewnij się, że backup pochodzi sprzed incydentu.
  - Zaktualizuj CMS, wtyczki, motywy do najnowszych wersji.

- 4) Rotacja haseł i kluczy
  - Zmień hasła wszystkich kont administracyjnych (CMS, hosting, SFTP, DB, CDN, e‑mail), włącz/wyegzekwuj 2FA.
  - Zrotuj klucze API (płatności, e‑mail, integracje) i sole/klucze aplikacji (w WP – `AUTH_KEY`, `SECURE_AUTH_KEY` itd.). Unieważnij aktywne sesje użytkowników.

- 5) Powrót do online i obserwacja
  - Wznów ruch stopniowo, monitoruj 5xx, ruch nietypowy, pliki zmieniane po przywróceniu. Ustaw alerty na wzorzec, który towarzyszył incydentowi.

- 6) Post‑mortem – wyciągamy wnioski
  - Krótkie, rzeczowe podsumowanie: jak doszło (przyczyna źródłowa), jak wykryto, ile trwało, jaki był wpływ, co naprawiono.
  - Działania zapobiegawcze: np. włączenie 2FA, usunięcie nieużywanych wtyczek, automatyczne aktualizacje bezpieczeństwa, dodatkowe reguły WAF, zmiana procesu wdrożeń (review, skany, staging).

- 7) Komunikacja do użytkowników (jeśli dotyczy)
  - Jeśli doszło do wycieku danych osobowych – obowiązki informacyjne wg RODO (zgłoś organowi, powiadom osoby, które mogły ucierpieć). Miej gotowy szablon jasnego, empatycznego komunikatu z faktami i poradą, co zrobić (np. zmiana hasła).

Ta kolejność ogranicza straty, skraca czas przestoju i porządkuje działania zespołu.

#### Dodatkowe praktyki „pro”, które kosztują mało, a dają dużo

- Minimalizacja powierzchni kodu: usuń nieużywane wtyczki i motywy. Każdy komponent to potencjalna podatność.
- Automatyczne aktualizacje łatek bezpieczeństwa (minor/patch). Duże aktualizacje testuj na stagingu.
- Oddzielne konta maszynowe dla CI/CD z ograniczonymi uprawnieniami.
- Rejestr dostępu (kto ma gdzie dostęp) i kwartalny przegląd. Po zakończeniu współpracy – natychmiastowe odebranie uprawnień.
- Alerty bezpieczeństwa vendorów: zapisz się do powiadomień o podatnościach narzędzi, których używasz.

#### Najczęstsze błędy i szybkie korekty

- Poleganie wyłącznie na wtyczce bezpieczeństwa – dołóż warstwę serwerową i WAF.
- Brak 2FA na hostingu i poczcie – to najszybszy „upgrade” bezpieczeństwa.
- Backup tylko na tym samym serwerze – przenieś kopie off‑site i przetestuj odtwarzanie.
- Publiczne środowiska testowe z danymi produkcyjnymi – zamknij dostęp i zanonimizuj dane.
- Nieaktualne wtyczki „bo działają” – największe źródło włamań. Ustal rutynę aktualizacji.

### Podsumowanie rozdziału

Hardening to zestaw prostych, ale skutecznych warstw: nagłówki bezpieczeństwa, blokady nadużyć, ograniczenia logowania, WAF, rozsądne uprawnienia i separacja środowisk. Do tego dochodzi higiena operacyjna: regularne, sprawdzone backupy (baza i pliki osobno), mocne hasła i 2FA, przegląd dostępów. Gdy mimo to zdarzy się incydent, masz plan: izolacja, skan, przywrócenie, rotacja kluczy, a potem krótkie post‑mortem i poprawki, które zamykają dziurę. Taki „ponad wtyczkę” poziom bezpieczeństwa sprawia, że atakujący wybierają łatwiejsze cele – a Twoja strona po prostu działa.